AsyncAPI 3.x: an E2E test, NCS driven through Kafka - #1810

Last of the AsyncAPI 3.x series, on top of #1809. Supersedes #1760, which could not be retargeted in place.

The SUT — NCS over Kafka

The NCS case study re-expressed as a message-driven service: six request topics (ncs.<op>.request), each answered on a reply topic with a result message or, for the inputs the REST version answers with a 400, an error message — exactly what ncs-kafka.yaml (already in core's test resources) describes. The routines are ported from EMB's org.restncs.imp and cited at the top of each file; the rejection rules mirror NcsRest. A Spring Boot application with no web layer: it speaks only Kafka, which is the point.

One deliberate deviation from the REST original: a result that is NaN or infinite is answered as an error. JSON has no such numbers, and a string where the contract promises a number would be a false fault.

And one deliberate defect, marked as such in NcsService where it is written: a triangle with a non-positive edge is answered with {"classification": ...}, a shape the document declares nowhere for that reply, where the original routine classifies it as 0 and answers with the declared result. It is there because the reply classifier's fault needs a service that commits it: the message arrives, it correlates, nothing times out, and a client written against the contract still cannot read it. Nothing else in a run notices. Worth knowing before reading the fixture as a faithful port — it is faithful everywhere else.

The driver — the reference executeAsyncApiAction

NcsKafkaController owns the broker (testcontainers, apache/kafka:3.8.0, KRaft), creates the twelve topics up front, and implements the hook as #1738's javadoc sketches it:

• publish with the correlation id in the header the document names — or stamped into the payload at the declared pointer, for documents that say so;
• the reply consumer is assigned and positioned at the end before publishing, so a fast reply cannot slip past, and reused for the rest of the run;
• wait until a record carrying the id arrives or replyTimeoutMs runs out; a reply carrying someone else's id is skipped, one carrying none is taken and reported as correlationMatched = false;
• fill AsyncApiReplyDto and judge nothing.

It answers getAsyncApiServerAddress with the address this run's broker actually listens on, so a generated test reaches it rather than the address the document declares.

Its reply consumers are dropped when the state is reset, since a search restarted under the same seed mints the same correlation ids again and a reply left on a topic by one test would otherwise answer a request of the next.

kafka-clients and testcontainers-kafka appear only in this test module, managed in the root pom.xml as the doc requires. Nothing is added to any shipped jar.

The search

AsyncApiTestBase joins the other bases in e2e-tests-utils: initAndRun, and helpers that read AsyncApiCallResult off the solution. NcsKafkaEMTest runs 300 action evaluations and asserts:

• every operation was answered;
• checkTriangle, bessj and remainder reached their result reply;
• expint and gammq reached both their result and their error — expint's x and gammq's a state their constraint in prose rather than as a bound, and fisher's x carries none at all, so the search is free to produce one. remainder's bounds are exactly the range the service checks, so no conforming client can provoke its error; bessj's n is fenced the same way, but its x is not, so an error there is reachable, just rare enough not to be asserted. The document says all of this beside each reply, so it does not read as a gap in the search;
• the undeclared reply is reported against checkTriangle, and nothing against the operations that answer correctly;
• no NO_REPLY, no PUBLISH_FAILED.

A second search runs with the oracles on and a reply deadline no round trip can meet, so every message goes unanswered and the no-reply fault is reported. Between the two, both sides of that gate are exercised against a live broker.

Because the driver is embedded, the SUT is instrumented, so the search covers lines and branches of a message-driven service as well: 662 targets in 26 seconds, identical on two runs.

The generated suite

The run writes the suite, compiles it and runs it against the same broker, so #1809 is covered by this E2E rather than by unit tests alone. Both JVM languages are covered: Kotlin in the first run, Java in a second one, since a Java half that never compiles is invisible to a Kotlin-only check. The shared compile step picks the compiler by whether the output folder holds .java or .kt sources.

CI

The module starts a broker in a container, so it wants Docker and is slower than the rest. It has an AsyncApiTests profile and a skipAsyncApi flag every other profile turns off, which is how the database E2Es are kept out of runs that have no business paying for them, with a matching CI job.